Programmable logic devices (PLDs) are a well-known type of integrated circuit that can be programmed to perform specified logic functions. One type of PLD, the field programmable gate array (FPGA), typically includes an array of configurable logic blocks (CLBs) and programmable input/output blocks (IOBs). The CLBs and IOBs are interconnected by a programmable interconnect structure. Some FPGAs also include additional logic blocks with special purposes (e.g., clock management circuits such as delay lock loops (DLLs), block RAM, processors, and so forth).
The interconnect structure, CLBs, IOBs, and other logic blocks are typically programmed by loading a stream of configuration data bitstream) into internal configuration memory cells that define how the logic blocks and interconnect are configured. The configuration data can be read from memory (e.g., an external PROM) or written into the FPGA by an external device. The collective states of the individual memory cells then determine the function of the FPGA.
Security of the configuration bitstream is a concern for some FPGA users. While configuration is the process of writing the configuration data to the FPGA, “readback” is the process of reading the configuration data from the configured FPGA. A bitstream read from a previously-configured FPGA could be used to configure other, similar, FPGAs, by persons other than those responsible for the original design. Alternatively, the bitstream could be used for reverse engineering a design, i.e., to obtain sensitive information about the design. Therefore, FPGAs typically include an option for disabling readback of the configuration bitstream, or for allowing readback only once (to allow confirmation that the device was configured properly), and then disabling the readback function. Thus, for most PLDs, bitstreams are safe from piracy (e.g., unauthorized duplication or analysis of the bitstream) once the PLD has been successfully configured.
However, a bitstream can potentially still be copied by an unauthorized person prior to (or during) the loading of the bitstream into the PLD. Both to prevent an intercepted bitstream from being used to configure a PLD, and to prevent reverse engineering of the design from the intercepted bitstream, some PLD providers provide bitstream encryption and decryption. In other words, the data in the bitstream is encrypted in such a way as to make it extremely difficult to extract information about the design implemented by the bitstream. The bitstream is then decrypted by decryption circuitry included in the PLD to regenerate the original (unencrypted) bitstream during the configuration process for the PLD. Without the decryption key, the bitstream cannot be decrypted, and the PLD cannot be successfully configured using the pirated bitstream.
Some currently available FPGAs offer both a CRC (cyclic redundancy check) feature and encryption/decryption capability. The CRC feature checks for transmission errors, while the encryption/decryption feature provides a strong barrier to bitstream piracy. One FPGA providing both CRC and encryption/decryption is the Virtex™-II FPGA available from Xilinx, Inc. The Xilinx Virtex-II FPGA is described in detail in pages 33-75 of the “Virtex-II Platform FPGA Handbook”, published in December, 2000 and available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124. The encryption/decryption feature of the Virtex-II FPGA is described briefly on page 75, and more fully on pages 307-310, of the same publication. Pages 33-75 and 307-310 of the Virtex-II Platform FPGA Handbook are incorporated herein by reference.
FIG. 1 illustrates a known method of generating a PLD bitstream and configuring a PLD using the bitstream. In FIG. 1, element 101 represents a bitstream implementing a design in a target PLD. The original bitstream includes not only configuration data for the PLD, but also a CRC value that represents the data in the bitstream. The original CRC value is used later in the configuration process to confirm that no errors (e.g., transmission errors or errors due to deliberate tampering) exist in the bitstream finally used to configure the PLD. CRC techniques are well known in the relevant arts.
In step 102, the original bitstream is encrypted using one or more user-supplied encryption keys 103. For example, three 56-bit DES (Data Encryption Standard) keys can be supplied to enable the well-known triple-DES encryption method. This step produces an encrypted bitstream 104. In the encrypted bitstream, the original CRC value can be encrypted or can remain unencrypted.
In step 105, the encrypted bitstream 104 is loaded into the target PLD. The PLD includes decryption circuitry. In addition, the user must supply one or more user-supplied decryption keys, which are typically the same as the encryption keys (i.e., element 103). For example, in a Virtex-II FPGA the decryption keys are loaded into the FPGA via a JTAG port, and the key data is maintained using an external battery. If the external battery fails or is disconnected, the key data is cleared from the key memory.
In step 106, the encrypted bitstream is decrypted by the decryption circuitry using the user-supplied decryption keys, providing a decrypted bitstream 107. The decrypted bitstream 107 is loaded into the PLD, i.e., stored in the configuration memory of the PLD (step 108). However, the PLD is not yet functional, as the power-up sequence has not been initiated.
In step 109, a new CRC value 110 is generated from the decrypted bitstream. In step 111, the original CRC value 112 is extracted from the decrypted bitstream. Thus, the original CRC value 112 represents the bitstream as it should be, and the new CRC value 110 represents the bitstream as actually used to configure the PLD.
Note that the steps illustrated in FIG. 1 are typically pipelined, i.e., several steps are occurring simultaneously on different parts of the bitstream. For example, a first group of bits (a first “bitstream word”) can be loaded into the PLD (step 108) while a second group of bits is used to calculate the new CRC value (step 109), and a third group of bits is being decrypted (step 106).
In step 113, the new and original CRC values are compared. If no errors have occurred in transit, the two CRC values should be the same. If the two CRC values match (decision step 114), the startup procedure for the configured PLD is performed (step 115), and the PLD begins to function according to the programmed design. If the new CRC value does not match the original CRC value (decision step 114), the startup process for the PLD is disabled (step 116), and the programmed design never becomes functional. The readback function can also be disabled in this situation. Thus, if the encrypted bitstream is subject to a transmission error (or to deliberate tampering) prior to step 105, the new and original CRC values do not match, and the design can be neither used nor studied.
If desired, a new bitstream download can be manually or automatically initiated (see arrow 117) after the detection of a CRC error. This procedure is commonly followed when CRC errors are assumed to be the result of transmission errors, e.g., when bitstream tampering is not a concern.
In theory, a decryption key could be discovered by using a pirated bitstream to repeatedly configure a PLD. Every possible combination of bits can be tried as the decryption key, until one combination results in a functional, configured PLD. However, since each test requires at least a few milliseconds, and there are typically at least 56 bits in the decryption key, this is a very time-consuming process. Even greater security is provided by using encryption/decryption methods such as the triple-DES method. When three 56-bit keys are used for encryption, as in the triple-DES method, it would take many years of effort to “break the code” for a single design. Therefore, the use of triple-DES encryption/decryption methods (or other highly secure methods) is highly desirable in situations where extreme security is required.
However, no matter what encryption/decryption algorithm is used, the configuration of a PLD with an encrypted bitstream requires the presence of the decryption key. Therefore, if reconfiguration of the PLD is enabled, the decryption key is generally stored in a special key memory in the PLD. In these situations, the configured, functional PLD remains, at least in theory, subject to reconfiguration by a “hostile” bitstream, e.g., by a bitstream created by an unauthorized person attempting to obtain sensitive information about the design.
Therefore, it is desirable to provide methods of detecting unauthorized bitstreams presented to a PLD in an attempt to reconfigure the device, and preventing the use of such bitstreams to obtain sensitive information. It is further desirable to detect and correct transmission errors in PLD configuration bitstreams. It is yet further desirable to differentiate between transmission errors and unauthorized attempts to access sensitive information by altering a configuration bitstream, thereby allowing a single PLD to address both of these two situations.